In recent years, the session Initiation Protocol (SIP) technique has been widely considered as a premier choice for locating user, setting session and managing session in IP (Internet Protocol) environments. Moreover, the SIP protocol is also adopted by the 3GPP (3rd Generation Partnership Project) as a call control protocol in an IP multimedia subsystem (IMS), which is a part of the Universal Mobile Telecommunication System (UMTS) protocol (Release 5/6) published by the 3GPP. The SIP is a text based signaling protocol for creating and controlling a multimedia session in which two or more parties attend. A SIP system usually adopts a client/server architecture commonly used in IP networks, defining several types of different servers and user agents to accomplish the call control and transport layers control via requests and responses to/from the servers.
FIG. 1 shows a typical SIP application architecture. As shown in FIG. 1, when service providers deploy applications based on the SIP technique, there exist large SIP application server clusters for hosting applications, and these SIP application servers simultaneously handle concurrent SIP sessions from a large amount of SIP terminals. The workload of these SIP application servers can affect the performance and quality of large-scale telecommunication services. In front of these SIP application server clusters, there is a SIP stateless proxy between the SIP terminals and the SIP application servers for receiving, pre-processing and forwarding SIP messages.
According to the SIP, SIP User Agents (UAs) are end system units of a call, which include a User Agent Client (UAC) and a User Agent Server (UAS). A SIP Transaction includes a procedure of the UAC sending requests to the UAS and the UAS returning all the responses to the UAC. In the discussion of the specification, the transaction can be categorized into “client transaction” and “server transaction” from the perspective of the SIP application servers. In FIG. 1, the client transaction is defined as a transaction in which the SIP application server serves as the UAC while the SIP terminal device serves as the UAS; in contrast, the server transaction is defined as a transaction in which the SIP application server serves as the UAS while the SIP terminal serves as the UAC.
The SIP is a type of signaling protocols, and the performance of transmitting and processing SIP messages is very important for SIP based applications. Many existed research works mainly focus on solving problems resulting from network environments and extremely high message flows. However, in practice, performance problems still exist and probably have serious impacts even when the workload is moderate and network resources are sufficient.
It is well known that the SIP is designed as a protocol independent of lower level transmission mechanisms. In practice, the User Datagram Protocol (UDP) is usually utilized to transmit SIP messages. Since the UDP does not ensure that the messages can be delivered reliably, a message retransmission mechanism is designed in the SIP to improve the reliability of message delivery. In fact, as the sender has no knowledge of the delivery procedure of the transmitted messages in the network, it can not be determined by the sender whether a certain message is lost or delayed during the process of message delivery or processing. Therefore when a required response message has not been received after a predetermined period of time, the sender will retransmit the transmitted message until the required response message has been received or the transmission has been timeout. If the initial message is not lost but delayed, and the sender has retransmitted the message, both of the initial message and the retransmitted message(s) will reach the destination. At this time, the retransmitted message does not carry more information, but increases the processing overhead at the destination, such retransmission is referred to as redundant retransmission. In an IP network, since a SIP User Agent (UA), which is located between a SIP terminal and a SIP application server, cannot have the global view of the SIP message transmission and processing, the redundant retransmission of the messages is inevitable and such redundant retransmission may heavily and negatively affect the performance of the application server when processing a large amount of SIP transactions.
FIG. 2 shows the transmission of the SIP messages among the SIP terminal, the SIP stateless proxy, and the SIP application server in the SIP application architecture as shown in FIG. 1 according to the prior art. As shown in FIG. 2, the SIP stateless proxy forwards all the SIP messages passing through it, including the initial and retransmitted SIP requests and responses. Redundantly retransmitted messages will increase the overhead of the SIP application server. When the number of the redundantly retransmitted messages cannot be neglected, these messages will considerably affect the performance of the SIP application server, for example, increasing CPU utilization ratio and memory usage, message processing delay, and/or decreasing the throughput, etc. Moreover, the quality of service (QoS) in the SIP application server would be affected if the retransmission overhead is heavy. Experiment data have shown that redundant retransmission occurs extensively and has the following severe impacts: more than 10% decrease of the throughput and tens of times increase of the processing delay in the SIP application server.
How to identity whether the transmissions are redundant retransmission or necessary transmission from the normally transmitted SIP messages and how to prevent the redundant retransmission or reduce the negative impacts of the redundant retransmission as much as possible is one of the important factors of improving the performance of the SIP application servers.
At present, there are several mechanisms in SIP to prevent the negative impacts of the message redundant retransmission. For example:
(1) The intervals of generating retransmitted messages obey an exponential back-offs rule. For example, for the same message, the first retransmission is issued in T1 Millisecond (ms) after the initial delivery, and the second retransmission is issued in 2*T1 ms if necessary, . . . , and so on.
(2) A SIP stateful proxy and UAs in the message delivery path can first provide a provisional response (e.g. a 1xx response) whenever receiving a request message. When provisional response is received, corresponding retransmission stops.
However, the above-mentioned mechanisms in the SIP can only decrease but not eliminate the redundant retransmission. For example, long path delay between the SIP UAs, long server response time etc may cause the retransmission. Generally, the processing of the retransmission is only performed in the UAs. However, the UAs are not the only proper location to identify and prevent the redundant retransmission. For example, in the typical SIP application architecture as shown in FIG. 1 in order to eliminate the impacts of the redundant retransmission, the SIP stateless proxy can be enabled to identify and reject the redundant retransmission of the messages so as to relief the workload of the SIP application servers.
Therefore, in consideration of the above mentioned circumstances, what is needed is a novel method and device for rejecting the redundant retransmission of SIP messages at the front end of SIP application server clusters, for example, in a SIP stateless proxy, so as to relief the workload of the SIP application servers.
In addition, in order to reject and eliminate the redundant retransmission of the SIP messages as much as possible, it is required to determine which of the messages are the redundantly retransmitted messages, therefore, it is necessary to allocate a certain amount of memory space for each SIP transaction to keep some necessary information about the transaction, in order to appropriately respond to the retransmitted messages. However, in the practical SIP applications, there are often numerous SIP transactions concurrently from a plurality of SIP terminals. Experiment data have shown that each SIP transaction needs at least 2 KB memory. Therefore, when there are a large number of SIP transactions in a SIP system at the same time, the required memory space can be considerably large. However, in many cases, the memory space is not sufficient, for example, in a switch, a multi-functional SIP stateless proxy or a SIP offload engine. In view that not all of the SIP transactions will retransmit some of their messages in the practical applications, storing necessary information for all the ongoing SIP transactions inevitably wastes the memory space.
Considering the fact that the memory space is often limited inmost cases, what is also needed is a method and device for allocating available memory space to SIP transactions tend to be retransmitted when the memory space is limited, so that the redundantly retransmitted SIP messages can be rejected with higher probability at the front end of the SIP application server, for example, in a SIP stateless proxy.